TCP ack frame

edit

I didn't notice your link to the tcp_dupack.cap capture so now I can accurately answer your question.

The capture was taken during a TCP Recovery event (i.e., one or more segments were not received or were delivered out-of-order). The receiver was in TCP recovery so it ACKed every data segment. Per Fast Retransmit/Fast Recovery RFC 5681 Section 3.2)) the sender waited for 3 duplicate ACKs before it retransmitted the first missing segment. Had that segment filled in the entire gap, the receiver would have resumed ACKing every other segment or two unless for the reasons discussed in my first answer, it could not. In this capture the gap was not filled and had the partners not agreed to use SACK the fast retransmission would have been followed by at least one "RTO" (i.e., a retransmission triggered by timeout). The latency caused by RTOs can greatly reduce throughput depending on the sender's retransmission timer period which varies among implementations from milliseconds (typical of those that set the timer dynamically) to several seconds. RTO latency is directly proportional to round-trip time (RTT) because the sender must wait for an ACK (any ACK) before it can send another segment. The latency caused by packet loss is reduced by TCP Fast Retransmit/Fast Recovery, SACK, and FACK because they reduce or eliminate RTOs. If only one segment is missing, Fast Retransmit/Fast Recovery prevents an RTO provided there is sufficient data sent following that packet to generate 3 dupacks. When more than one packet is missing, an RTO is inevitable unless SACK or SACK+FACK is also employed. However, if the final segment of a PDU is smaller than the MSS, an RTO will occur because only full sized segments are ACKed. The receiver has no idea if a small packet is the end of a PDU or the result of the sender's cwnd (not to mention that TCP knows nothing about PDUs because it's an upper layer concept).

Had the capture been longer, thanks to SACK we would have seen more packets sent within the gap without RTT delays provided the receiver's window and the sender's congestion windows allowed.

The right edge of the gap continued to grow in frames 3, 5, and 7, as new data was received which begs the question, why did the gap in the SACK range grow despite the segments received in frames 2, 4, and 6? Those packets were in fact not received which conclusively demonstrates that the capture was taken on the sender's side of the connection. Had it been taken on the receiver's side, those packets would have been absent.

There is nothing wrong with an ACK for every data packet. This is the behavior of TCP as specified in RFC 793, the original TCP RFC. Now, with the Delayed ACK enhancement, it is no longer necessary to have an ACK for every data packet, but it is still allowed. The use of Delayed ACK is optional. A good idea, but optional.

Delayed ACK may or may not be in use on this communication, but in this case these ACKs are Duplicate ACKs. There is packet loss, so every incoming packet causes a Duplicate ACK to be sent.

Packet 2, the first packet in this trace from 195.81.202.68, has relative sequence number 10,945. Packet 8, also from 195.81.202.68, has relative sequence number 1 and is identified as a Fast Retransmission.

Unfortunately, this capture file is very short and most of this has to be inferred. When the capture starts, the packet with relative sequence number 10,945 has been sent and received. The packet with relative sequence number 1 has been sent but not received. It's missing. There may be other missing packets as well. It's not possible to tell from the capture file.

Because of the missing packet, there is a gap in the sequence numbers, so every incoming data packet causes a Duplicate ACK to be sent.

In simple terms, suppose I send packets 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10, but you receive packets 1, 2, 3, 4, 6, 7, 8, 9, and 10. Packet 5 is missing. As soon as you receive packet 6, you will detect that there is a gap after packet 4, so you will send a Duplicate ACK when packets 6, 7, 8, 9, and 10 are received. You will keep sending Duplicate ACKs until the missing packet is received and there is no longer a gap in the sequence numbers.

RFC 1122 Section 4.2.3.2, states "in a stream of full-sized segments there SHOULD be an ACK for at least every second segment." As you probably are aware, per the Delayed Ack algorithm, most TCP implementations send an ACK for every two or three full-sized segments. It seeks to limit the number of ACKs because, among other things, they can cause excessive interrupts on the sender. In cases where the latency introduced by this method reduces throughput to unacceptable levels, the delayed ACK period can be reduced.

Most implementations immediately ACK segments with the PSH bit set. The PSH bit essentially indicates "I've got no more data to send right now." This may cause the receiver to immediately ACK that segment regardless of the Delayed ACK period, and immediately transfer the data to the upper layer protocol; however, at least some implementations provide an option to ignore PSH bits.

Nagle is designed to coalesce short segments. If there is unACKed data, the sender buffers all outgoing data on a given TCP connection regardless of the PSH bit until all outstanding data has been ACKed or the sender can transmit a full-sized segment. In some environments where short segments are the norm, Nagle can be disabled if it results in poor performance. Nagle can be especially harmful with data streaming applications.

Here are some possible explanations for the behavior you mentioned:

o The Delayed ACK timer has been reduced or set to zero.

o The sender is setting the PSH bit in every segment and the receiver ACKs every PSH bit segment.

o The receiver's TCP provides an option to ACK every segment regardless of segment size, PSH bit, or Delayed ACK timer.

If performance is unacceptable, I would check the capture to see if every segment has the PSH bit set. If so, the receiver TCP might have an option to ignore them. If Nagle is disabled on the sender, it could be enabled. If the Delayed ACK period has been set to a very low value on the receiver, it could be increased. Of course, these measures should be tested individually and depending on the behavior seen in the captures, tested in prescribed combinations.